I've finished my work on getting on-the-fly workgroups working for projects, and have set up the staging environment for RI-ITEST to use the new system so that you can test it out.

What this does:
When a student launches (the lead user) the activity, they will be presented with a list of users in their class. They can select 0 or more users which are designated as working together with them on the activity (the other members). When the students close the activity, the data is copied out to the other member's accounts, so that if they launch the activity, all of the data will be available.

Portal: http://ri-itest.portal.dev.concord.org/
DIY: http://ri-itest.staging.concord.org/

To test it, set up a class with several members. Sign in as one of the members and launch the activity. Then select some other workgroup members. Answer some questions in the activity, then quit. Wait 5-10 minutes to make sure the processing on the server has happened. Then sign-in and launch the activity as one of the other workgroup members. You should see all of your previous work.

You'll need to use the Chemical Bonds (v1) activity, as that's the only one I've set up to use the new workgroup chooser.
You can see what changes I made by comparing version 1b with 1c: http://svn.concord.org/svn/projects/trunk/ri-itest/activities/chemical-bonds/chemical-bonds-v1b.otml http://svn.concord.org/svn/projects/trunk/ri-itest/activities/chemical-bonds/chemical-bonds-v1c.otml

How this works:

This code uses a number of new features in the DIY, the SDS and OTrunk:
1) SDS Notifications
2) SDS Bundle copying
3) DIY Notification handling
4) OTrunk OTGroupListManager

The actual flow:
1) The student tells the Portal to launch the activity
2) The portal tells the DIY which users are in the student's class
3) The DIY renders a special overlay otml file which wraps the original activity otml and includes the class info in the OTGroupListManager
4) When the activity launches, the student selects their workgroup members and works on the activity as normal
5) When the student closes the activity, the session data is posted to the launching student's workgroup in the SDS
6) The SDS looks at the bundle and sees if there are any registered NotificationListeners that apply to that bundle. If there are, it sends a notification to that listener's url.
7) The DIY receives the notification.
8) The DIY gets the bundle's ot_learner_data and parses it to find the lead workgroup member (the student who logged into the portal and launched the activity) and the other members of that workgroup.
9) The DIY copies the bundle to each of the other members' SDS workgroups.

NOTE: The bundle copying happens asynchronously, which means there will be a variable time gap between when the original bundle was posted and when one of the other workgroup members would be able to sign in and see the work (how long depends on things like server load, how many bundles are in the queue to be processed, etc.). This leads to a potential race condition where the data could potentially get "lost", but as long as workgroups aren't switching student accounts in the middle of a class, I don't think it will be a problem.

Good questions.

If any of the other members of a group have previously run the activity, they will no longer see their old data. They will inherit the data as it exists for the workgroup leader ("leader" just indicates which user signed into the portal and launched the activity).

So for instance:
Workgroup A (User 1 - leader, User 2) and Workgroup B (User 3 - leader, User 4) run the activity.
User 1 => Workgroup A data
User 2 => Workgroup A data
User 3 => Workgroup B data
User 4 => Workgroup B data
now they switch up, User 1 is leader with User 3, User 4 is leader with User 2. When they save:
User 1 => Workgroup A` data
User 2 => Workgroup B` data
User 3 => Workgroup A` data
User 4 => Workgroup B` data

likewise, if instead User 4 leaves Workgroup B to join Workgroup A, then the data would look like:
User 1 => Workgroup A` data
User 2 => Workgroup A` data
User 3 => Workgroup B` data
User 4 => Workgroup A` data

The data that gets save back to the server is everything that the user/workgroup has modified. So if the user only fills in one text box, then only what they filled in gets sent to the server. This, however, is cumulative. So if they launch the activity for a second time, alter a different text box and leave the first one unchanged, they will still send back the contents of both text boxes. This isn't usually a problem, except in the case of things like snapshots which are very data intensive... Scott and I were discussing ways to extract the raw snapshot data out of the student session data so that it doesn't need to get transferred back and forth so much.

– Aaron

On Jan 30, 2009, at 1:58 PM, Dan Damelin wrote:

Thanks Aaron. I'll test this out on Monday.

What happens when the lead user selects some group members to work with, but some of them have worked on the activity already. It might be possible in a group of three running the activity for a second time, that there are already three distinct sets of data on the server to be retrieved. Which data gets populated into the activity when it restores the user data?

Also, what happens when a user is part of one group on day 1, but then switches to a new group on day 2. Does the original data from day 1 get overwritten by the data from day 2?

And a related question: When closing an activity is ALL of the data uploaded from the entire activity, or just the changed data?

-Dan